Use @Catch() with no argument to catch everything. Branch on instanceof HttpException — known HTTP exceptions expose their status and message to the client. Unknown errors are logged in full server-side but return a generic 500 to the client. This two-branch pattern is the production standard.

Production global all-exceptions filter

Production error handling best practices:

1
Always log the full error including stack trace for unexpected errors.
2
Never expose internal error details, stack traces, or DB errors to the client.
3
HTTP exceptions are expected client errors — surface their message and status code.
4
Unknown errors should always return 500 with a generic message.
5
Include the request path and timestamp in error responses for client-side debugging.

Difficulty: 7/10

Topics: Exception handling, NestJS filters, Error logging

Scenario Questions

0-2 years experience

1
Imagine you need to add a global exception filter to a small NestJS service that returns a 400 response for HttpException and a generic 500 for any other error. How would you implement that filter?
2
If you forget to call next.handle() inside your filter's catch method, what would happen to the request lifecycle?
3
How would you register this filter so that it applies to all controllers without modifying each one?

2-5 years experience

1
You added a global filter that logs errors, but now some HttpExceptions are losing their original status codes. What could be causing that and how would you fix it?
2
During a load test, you notice the filter is adding significant latency. What trade‑offs would you consider to keep error handling robust yet performant?
3
Your team wants the filter to differentiate between client errors (4xx) and server errors (5xx) for monitoring. How would you extend the filter to support that without breaking existing behavior?

5-8 years experience

1
In a microservices architecture, several NestJS services share a common library for exception handling. How would you design the global filter to be reusable across services while still allowing each service to inject its own logger or monitoring client?
2
When deploying to Kubernetes, you see that unhandled errors sometimes cause the process to crash despite the filter. Explain why that might happen and how you would make the filter truly production‑ready.
3
Consider that some HttpExceptions contain sensitive data in their response payload. How would you modify the filter to sanitize responses while still preserving useful debugging info for internal logs?

8+ years experience

1
Your organization is migrating legacy Express middleware to NestJS. How would you approach integrating existing error‑handling middleware with a new global NestJS exception filter to ensure a seamless transition?
2
Across multiple teams, there’s a need for a standardized error contract (error codes, messages, correlation IDs). How would you evolve the global filter and related infrastructure to enforce this contract at scale?
3
If you had to support both synchronous and asynchronous exception sources (e.g., RxJS streams, Promise rejections) in a single filter, what architectural changes would you make to keep the code maintainable and testable?

Follow-up Questions

❓What would you do if you needed to add a correlation ID to every error response?
❓How do you ensure the filter doesn't swallow stack traces needed for debugging?
❓Can you explain how NestJS's built‑in HttpException filter differs from a custom one?